home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 #1 / Ham Radio 2000.iso / ham2000 / tcp_ip / ka9q / nosvw304 / ripnotes < prev    next >
Encoding:
Text File  |  1992-07-26  |  10.3 KB  |  256 lines
  1.  
  2.                    RIP - Routing Information Protocol
  3.  
  4. This is a doc that explains how I feel RIP should be used in the UK for
  5. the amateur service. Please pass comments on this doc as necessary.
  6.  
  7. RIP is Routing Information Protocol and is used on TCP/IP networks to
  8. spread routing information. It however is not readily adaptable to the
  9. radio network without some careful planning. It is NOT a flooding system
  10. like NET/ROM uses and thus it is more complex. The damage that can be done
  11. by speading false or incorrect information is more serious.
  12.  
  13. I don't intend to bore you with the details, only to explain the advantages
  14. and disadvantages of using RIP, and how to get going.
  15.  
  16. To use a real-life situation I've reproduced part of the local network as
  17. it runs at present. On top of this I'll then explain how RIP could make it
  18. easier. 
  19.  
  20. We currently have a BIG problem in dropping NET/ROM routing in favour of 
  21. RIP and that is that a lot of people are not yet using a version of NET with
  22. RIP available.
  23.  
  24.  
  25. g1emm ----- g4bio
  26.  \           / \           g1sls
  27.   \         /    \           /
  28.    \       /       \        /
  29.     \     /          \     /
  30.      \   /             \  /
  31.      g1wkk             g1bys 
  32.                         |  \
  33.                         |    \
  34.                         |      \
  35.                         |        \
  36.                       g6jha     g8zhr
  37.  
  38. Assuming that everyone is running RIP, then the following information ONLY
  39. is added to the routing table ( using route add host )
  40.  
  41. g1emm          g4bio          g1bys         g1sls          g8zhr        
  42. -----          -----          -----         -----          -----         
  43. rou add g1wkk  rou add g1bys  rou add g1sls rou add g1bys  rou add g1bys
  44. rou add g4bio  rou add g1emm  rou add g7gbq
  45.                rou add g1wkk  rou add g6jha
  46.                               rou add g8zhr
  47.  
  48. g1wkk          g7gbq          g6jha
  49. -----          -----          -----
  50. rou add g1emm  rou add g1bys  rou add g1bys
  51. rou add g4bio
  52.  
  53. Then you will need to set-up who you will send RIP to and who to accept it
  54. from. This is quite easy. If you are a stub in the network then accept
  55. information from your gateway, but don't broadcast it. If you are used as
  56. a gateway then accept from other gateways, and broadcast to all hosts 
  57. including stubs. See below using our example network.
  58.  
  59. Each route times out after 4800 seconds ( I haven't worked out if this bit
  60. is configureable ( Kelvin?? )), unless updated. A route cost of one is added
  61. by default but you can change this by adding a metric value to your route add
  62. commands.
  63.  
  64. So in our example network the following commands are entered.
  65.  
  66. g1emm               g4bio                g1bys               g8zhr
  67. -----               -----                -----               -----
  68. rip accept g4bio    rip accept g1emm     rip accept g4bio    rip accept g1bys
  69. rip add g4bio 1200  rip add g1emm 1200   rip add g4bio 1200
  70. rip accept g1wkk    rip accept g1wk      rip add g1sls 1200
  71. rip add g1wkk 1200  rip add g1wkk 1200   rip add g8zhr 1200
  72.                                          rip add g6jha 1200
  73.                                          rip add g7gbq 1200
  74.  
  75. g1wkk               g6jha              g1sls              g7gbq
  76. ------              -----              -----              -----
  77. rip accept g1emm    rip accept g1bys   rip accept g1bys   rip accept g1bys
  78. rip add g1emm 1200
  79. rip accept g4bio
  80. rip add g4bio 1200
  81.  
  82. As you can see the routing not that difficult but requires thought. DO NOT
  83. add cluster routes unless you really mean it. You can break the routing if
  84. you do. Only add to your routing table hosts that are directly accessable
  85. to you.
  86.  
  87. To start RIP running you must have a line 
  88.  
  89. start rip 
  90.  
  91. in your autoexec.net. It is also necessary to have the line RIP merge if
  92. you take routing information from more than 1 host. If a particular host
  93. is sending bogus routes, you can use
  94.  
  95. rip refuse <host>
  96.  
  97. to ignore their routing information.
  98.  
  99.  
  100. To start the ball rolling, right at the end of your autoexec.net add lines
  101. like 
  102.  
  103. rip request <host>
  104.  
  105. for all your gateways. This will request the lastest information from your
  106. gateways and add it to your routing table.
  107.  
  108. Thats it, not too painful I hope.
  109.  
  110. Advantages
  111. ----------
  112.  
  113. 1, With this system is that we are no longer NET/ROM dependant
  114. except where necessary, and thus our packet overhead is reduced. 
  115.  
  116. 2, Also a simpler set of route add's is all that is required to read in 
  117. upon boot.
  118.  
  119. 3, More reliable IP routing to distant hosts.
  120.  
  121. 4, Dynamic IP routing as opposed to fixed routing with NET/ROM bodge.
  122.  
  123.  
  124. Disadvantages
  125. -------------
  126.  
  127. 1, Easily broken routing if cluster routing is used.
  128.  
  129. 2, Difficult to use in a mixed NET/ROM / RIP routing environment.
  130.  
  131.  
  132. As far as I'm concerned the quicker we get RIP going the better.
  133.  
  134. Your comments and suggestions on this are welcome, plus results of any
  135. over the radio tests.
  136.  
  137. Keith Brazington
  138. 27/3/90
  139.  
  140. To start accepting the RIP broadcasts, merely say:
  141.  
  142. start rip
  143.  
  144. If you're not acting as a gateway to anyone,  this is all you need do --
  145. your system will begin to passively monitor its interfaces for broadcast
  146. routing  packets  and  it will automatically add routes to  the  routing
  147. table.   It may take up to 30 seconds on an Ethernet for the table to be
  148. built (this assumes a broadcast rate of 30 seconds, which is standard on
  149. Ethernet).   If you want to get started faster, you can give an optional
  150. IP address to the command:
  151.  
  152. start rip [128.96.160.0]
  153.  
  154. This  broadcasts  a  RIP "request"  packet on the local  subnet,   which
  155. triggers  each  gateway within earshot to send you its  routing  tables.
  156. (This requires knowledge of the local IP broadcast address,  plus an ARP
  157. entry for same.  Read on to find out about both of these things.)
  158.  
  159. If  you  are also acting as a gateway,  then you'll want to  enable  the
  160. transmit  routines.   First add ARP entries that map the local broadcast
  161. address for each of your networks to the correct hardware address.   For
  162. example,  the IP broadcast address on my shack ethernet is 128.96.160.0,
  163. so I include the line
  164.  
  165. arp add [128.96.160.0] ethernet ff:ff:ff:ff:ff:ff
  166.  
  167. in  my  /autoexec.net file.   Then i enable the broadcasting of  routing
  168. info with the line
  169.  
  170. rip add [128.96.160.0] ethernet 30 6
  171.  
  172. This  means  "broadcast"   your routing tables every 30 seconds  on  the
  173. interface  named 'ethernet',  using IP destination address 128.96.160.0.
  174. Generate triggered updates as necessary, and use spit horizon method."
  175.  
  176. On a packet radio channel, i might use the following lines:
  177.  
  178. arp add [44.64.0.0.] com1 qst-0
  179.  
  180. rip add [44.64.0.0.] com1 600 7
  181.  
  182. The last parameter in the "rip add"  command is the flag parameter.   It
  183. is the sum of the following possible values:
  184.  
  185. 1 - Include  a  host-specific route to yourself in each  update.    (Not
  186.     needed  if you're already advertising a route to the network  you're
  187.     on.)
  188.  
  189. 2 - Use  spit horizon updating;  that is,  omit all routing entries that
  190.     point  to the interface being used on the broadcast.   (This reduces
  191.     the chances of routing loops forming).
  192.  
  193. 3 - Generate  triggered  updates as necessary on this interface,   i.e.,
  194.     whenever a metric changes in the routing table, immediately generate
  195.     a  broadcast on this interface with the changed entries.   If  split
  196.     horizon (bit2) is also set,  use "poisoned reverse",  i.e.,  for any
  197.     routing  table  entries that point to this interface,  include  them
  198.     with  an infinite metric (RIP defines 16 to be infinity)  instead of
  199.     leaving  them out as happens during a normal routing broadcast  when
  200.     split horizon is set.  Triggered updates helps spead the word faster
  201.     when links fail, reducing the chances of a temporary loop forming.
  202.  
  203. For Ethernet, I recommend a flag value of 6 (triggered updates and split
  204. horizon).   On SLIP links,  use 6 or 7, depending on whether you need to
  205. emit a host-specific route to yourself.  On a packet radio channel where
  206. everyone  is  not  fully connected (the usual case),  use  7  and  DON'T
  207. advertise  any  routes to the subnet unless you can reach every  one  on
  208. that subnet.
  209.  
  210. (A  packet  radio  channel is best modeled as a collection of  point  to
  211. point   links  links  since  it  rarely  fits  the  model  of  a   fully
  212. interconnected  subnet  like  Ethernet.)   Note that you  dont  have  to
  213. broadcast your routes; you can direct them to a specific set of stations
  214. by  using their names or addresses in the "rip add"  command.   You  can
  215. have  any  number of such commands per interface,  with the  only  limit
  216. being channel traffic overhead.
  217.  
  218. An experimental parameter is available to control somthing i call "route
  219. merging".    If you say "rip merge on",  then an incoming route that  is
  220. more  specific than the one you already have in your table is ignored if
  221. they both point to the same gateway.  For example, if you already have a
  222. default  route  that  points to gatway "foobar",  then  any  route  that
  223. arrives  from  gateway foobar will be ignored because ot put it  in  the
  224. table  would  not cause any change in the routing of packets  --  they'd
  225. still  go  to foobar anyway.   Properly used,this should save a  lot  of
  226. routing table space.
  227.  
  228. You  can  trace the automatic routing messages and controls by the  "rip
  229. trace"  command;  it takes a numeric parameter.   "rip trace 0" disables
  230. tracing,  "rip trace 1" generates messages only when routes change,  and
  231. "rip trace 2" shows you everything, even when things are stable.
  232.  
  233. If  you want to ignore routing broadcasts from a certain gateway  (e.g.,
  234. because it can't hear you), say
  235.  
  236. rip refuse hostname
  237.  
  238. where  'hostname'   is a domain name or [ip address]  of  the  offending
  239. gateway.  To reverse this, just say
  240.  
  241. rip accept hostname
  242.  
  243. This  manual  filtering will probably do until I'm able to  devise  some
  244. sort  of  link connectivity algorithm and protocol than can analyze  the
  245. quality  of the path between your station and each of your neighbours so
  246. routing packets can be filtered automatically.  I have an idea how to do
  247. this  -- by broadcasting periodic status packets containing received and
  248. transmitted  packet count statistics and using such packets to determine
  249. how well you're being heard.
  250.  
  251. Thanks  to N6TTO for contributing the original version of this code that
  252. was the starting point for my hacking over the past week or so.
  253.  
  254.  
  255. *** EOF
  256.